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Status of this Memo 


This RFC specifies a standard for the Internet community. Authors of 
RFCs are expected to adopt and implement this standard. Distribution 
of this memo is unlimited. 


1. Introduction 


RFCs are distributed online by being stored as public access files, 
and a short message is sent to the distribution list indicating the 
availability of the memo. 


The online files are copied by the interested people and printed or 
displayed at their site on their equipment. (An RFC may also be 
returned via email in response to an email query.) This means that 
the format of the online files must meet the constraints of a wide 
variety of printing and display equipment. 


2. Format Rules 


To meet the distribution constraints the following rules are 
established for the two allowed formats for RFCs: ASCII and 
PostScript. 


The RFC Editor attempts to ensure a consistent RFC style. To do this 
the RFC Editor may choose reformat the RFC submitted. It is much 
easier to do this if the submission matches the style of the most 
recent RFCs. Please do look at some recent RFCs and prepare yours in 
the same style. 

You must submit an editable online document to the RFC Editor. The 
RFC Editor may require minor changes in format or style and will 
insert the actual RFC number. 

2a. ASCII Format Rules: 


The character codes are ASCII. 


Each page must be limited to 58 lines followed by a form feed on a 
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2b. 


line by itself. 


Each line must be limited to 72 characters followed by carriage 
return and line feed. 


No overstriking (or underlining) is allowed. 


These "height" and "width" constraints include any headers, 
footers, page numbers, or left side indenting. 


Do not fill the text with extra spaces to provide a straight right 
margin. 


Do not do hyphenation of words at the right margin. 


Do not use footnotes. If such notes are necessary, put them at 
the end of a section, or at the end of the document. 


Use single spaced text within a paragraph, and one blank line 
between paragraphs. 


RFCs in ASCII Format may be submitted to the RFC Editor in email 
messages (or as online files) in either the finished publication 
format or in NROFF. If you plan to submit a document in NROFF, 
please consult the RFC Editor first. 


PostScript Format Rules 


Standard page size is 8 1/2 by 11 inches. 


Postel 


Margin of 1 inch on all sides (top, bottom, left, and right). 


Main text should have a point size of no less than 10 points with 
a line spacing of 12 points. 


Footnotes and graph notations no smaller than 8 points with a line 
spacing of 9.6 points. 


Three fonts are acceptable: Helvetica, Times Roman and Courier 
Plus their bold-face and italic versions. These are the three 
standard fonts on most PostScript printers. 


Prepare diagrams and images based on lowest common denominator 
PostScript. Consider common PostScript printer functionality and 
memory requirements. 


The following PostScript commands should not be used: 
initgraphics, erasepage, copypage, grestoreall, initmatrix, 
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3; 


initclip, banddevice, framedevice, nulldevice and renderbands. 


These PostScript rules are likely to changed and expanded as 
experience is gained. 


RFCs in PostScript Format may be submitted to the RFC Editor in 


email messages (or as online files). Since PostScript is not 
editable, an editable source version of the document must also be 
submitted. If you plan to submit a document in PostScript, please 


consult the RFC Editor first. 
Status Statement 


Each RFC must include on its first page the "Status of this Memo" 
section which contains a paragraph describing the intention of the 
RFC. This section is meant to convey the status granted by the RFC 
Editor and the Internet Activities Board (IAB). There are several 
reasons for publishing a memo as an RFC, for example, to make 
available some information for interested people, or to begin or 
continue a discussion of an interesting idea, or to make available 
the specification of a protocol. 


The following sample paragraphs may be used to satisfy this 
requirement: 


Proposed Protocol 
This RFC suggests a proposed protocol for the Internet 
community, and requests discussion and suggestions for 
improvements. 

Specification 
This RFC specifies a standard for the Internet community. 


Hosts on the Internet are expected to adopt and implement 
this standard. 


Discussion 


The purpose of this RFC is to focus discussion on particular 
problems in the Internet and possible methods of solution. 
No proposed solutions this document are intended as 
standards for the Internet. Rather, it is hoped that a 
general consensus will emerge as to the appropriate solution 
to such problems, leading eventually to the adoption of 
standards. 
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4. 


Information 


This RFC is being distributed to members of the Internet 
community in order to solicit their reactions to the 
proposals contained in it. While the issues discussed may 
not be directly relevant to the research problems of the 
Internet, they may be interesting to a number of researchers 
and implementers. 


Status 


In response to the need for maintenance of current 
information about the status and progress of various 
projects in the Internet community, this RFC is issued for 
the benefit of community members. The information contained 
in this document is accurate as of the date of publication, 
but is subject to change. Subsequent RFCs will reflect such 
changes. 


These paragraphs need not be followed word for word, but the 
general intent of the RFC must be made clear. 


Distribution Statement 


Each RFC is to also include a "distribution statement". In general, 
RFCs have unlimited distribution. There may be a few cases in which 
it is appropriate to restrict the distribution in some way. 


Typically, the distribution statement will simply be the sentence 
"Distribution of this memo is unlimited." appended to the "Status of 
this Memo" section. 


Author’s Address 


Each RFC must have at the very end a section giving the author's 
address, including the name and postal address, the telephone number, 
and the Internet email address. 


Relation to other RFCs 


Sometimes an RFC adds information on a topic discussed in a previous 
RFC or completely replaces an earlier RFC. There are two terms used 
for these cases respectively, UPDATES and OBSOLETES. A document that 
obsoletes an earlier document can stand on its own. A document that 
merely updates an earlier document cannot stand on its own; it is 
something that must be added to or inserted into the existing 
document, and has limited usefulness independently. The terms 
SUPERSEDES and REPLACES are no longer used. 


Postel [Page 4] 


RFC 1111 RFC Instructions August 1989 


UPDATES 


To be used as a reference from a new item that cannot be used 
alone (i.e., one that supplements a previous document), to refer 
to the previous document. The newer publication is a part that 
will supplement or be added on to the existing document; e.g., an 
addendum, or separate, extra information that is to be added to 
the original document. 


OBSOLETES 


To be used to refer to an earlier document that is replaced by 
this document. This document contains either revised information, 
or else all of the same information plus some new information, 
however extensive or brief that new information is; i.e., this 
document can be used alone, without reference to the older 
document. 


For example: 


On the Assigned Numbers RFCs, the term OBSOLETES should be used 
since the new document actually incorporates new information 
(however brief) into the text of existing information and is 
more up-to-date than the older document, and hence, replaces it 
and makes it OBSOLETE. 


In lists of RFCs or the RFC-Index (but not on the RFCs themselves), 
the following may be used with early documents to point to later 
documents. 


OBSOLETED-BY 


To be used to refer to the newer document that replaces the older 
document. 


UPDATED-BY 


To be used to refer to the newer document that adds information to 
the existing, still useful, document. 
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7. The RFC Editor 
The RFC Editor is Jon Postel. 

8. The RFC Announcement List 
New RFCS are announced to the RFC distribution list maintained by the 
SRI Network Information Center (NIC). Contact the SRI-NIC to be 


added or deleted from this mailing list by sending an email message 
to RFC-REQUEST@NIC.DDN.MIL. 


9. Obtaining RFCs 


RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname 
RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC). 
Login with FTP, username ANONYMOUS and password GUEST. 


The NIC also provides an automatic mail service for those sites which 
cannot use FTP. Address the request to SERVICE@NIC.DDN.MIL and in 
the subject field of the message indicate the RFC number, as in 
"Subject: RFC nnnn". 


Requests for special distribution (for example, hardcopy) should be 
addressed to either the author of the RFC in question, or to 
NIC@NIC.DDN.MIL. 


Unless specifically noted otherwise on the RFC itself, all RFCs are 
for unlimited distribution. 


The RFCs may also be obtained from other information centers, 
including the CSNET Information Center (INFO@SH.CS.NET), the NSFNET 
Information Service (INFO@NIS.NSF.NET). 
Author’s Address 
Jon Postel 
USC Information Sciences Institute 
4676 Admiralty Way 
Marina del Rey, California 90292-6695 
Phone: 213-822-1511 


EMail: POSTEL@ISI.EDU 
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